home *** CD-ROM | disk | FTP | other *** search
/ Collection of Internet / Collection of Internet.iso / infosrvr / dev / www_talk.930 / 000360_marca@wintermu….ncsa.uiuc.edu _Thu Nov 19 20:45:16 1992.msg < prev    next >
Internet Message Format  |  1994-01-24  |  2KB
  1. Return-Path: <marca@wintermute.ncsa.uiuc.edu>
  2. Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
  3.     id AA16783; Thu, 19 Nov 92 20:45:16 MET
  4. Received: by dxmint.cern.ch (dxcern) (5.57/3.14)
  5.     id AA21652; Thu, 19 Nov 92 20:57:50 +0100
  6. Received: from wintermute.ncsa.uiuc.edu by newton.ncsa.uiuc.edu with SMTP id AA09475
  7.   (5.65a/IDA-1.4.2 for www-talk@nxoc01.cern.ch); Thu, 19 Nov 92 13:53:26 -0600
  8. Received: by wintermute.ncsa.uiuc.edu (920110.SGI/911001.SGI)
  9.     for @newton.ncsa.uiuc.edu:rik@daneel.rdt.monash.edu.au id AA10782; Thu, 19 Nov 92 13:54:21 -0800
  10. Date: Thu, 19 Nov 92 13:54:21 -0800
  11. From: marca@ncsa.uiuc.edu (Marc Andreessen)
  12. Message-Id: <9211192154.AA10782@wintermute.ncsa.uiuc.edu>
  13. To: www-talk@nxoc01.cern.ch
  14. Cc: rik@daneel.rdt.monash.edu.au
  15. Subject: [rik@daneel.rdt.monash.edu.au: Re: hangs/multiple servers ]
  16. In-Reply-To: <9211192142.AA10729@wintermute.ncsa.uiuc.edu>
  17. References: <9211192142.AA10729@wintermute.ncsa.uiuc.edu>
  18.  
  19. > One possible way to implement backups is to have the client do it
  20. > (makes the client too clever?).  The client could have a list of
  21. > hosts, and for each one, have a list of backup servers, to try if
  22. > the main server is down.  The problem with this is that the list is
  23. > much more difficult to maintain, if everyone needs a copy, and only
  24. > the clients that have implemented this would benefit.
  25.  
  26. I think this is a good idea -- the really important capability it
  27. enables is this: if I (I == ``real user using WWW mechanisms for real
  28. work'') set up an HTTP server that people at my site will need to get
  29. to at all times, then with this mechanism I could *at the very least*
  30. tell my WWW clients about alternate servers that I also set up.
  31.  
  32. A big advantage is that nothing major (i.e., HTTP or HTML) would have
  33. to be changed.
  34.  
  35. As for the problems: (1) it is true that to be useful in the general
  36. sense a master list would have to be maintained, but each local site
  37. would only have to pull down a new one every few months -- these
  38. things aren't going to change that often (expansion is more likely),
  39. and (2) is a problem with any change of anything at this point, which
  40. is why I think a very lightweight change (like this) would be best.
  41.  
  42. Marc
  43.  
  44. --
  45. Marc Andreessen
  46. Software Development Group
  47. National Center for Supercomputing Applications
  48. marca@ncsa.uiuc.edu
  49.